Hec'd P0r/PT8 02 DEC ' V-S"/ 



(12) NACH DEM VCRTRAG VlfflffDm INTERNATIONALE ZUSAMMEN ARBEIT l^^EM GEBIET DES 
PATENTWESENS (Pct) VEROFFENTLICHTE INTERNATIONALE ANMELDUNG 



r 



(19) WeltorganisatioD fOr geistiges Eigentum 
Internationales Biiro 

(43) Internationales Ver5ffentHchungsdatuni 
18. Dezember 2003 (18.12.2003) 




(10) Internationale VerdffentHcbungsnummer 

wo 03/105435 Al 



(51) Internationale Patentklassifikation^: 

H04Q 7/30 

(21) Internationales Aktenzeicben: 



H04L 29/06, 



PCT/EP02/06268 



(22) Internationales Anmeldedatum: 

7. Juni 2002 (07.06.2002) 



(25) Einreichungssprache: 

(26) VerdfTentliehungssprache: 



Deutsch 
Deutsch 



(71) Anmelder (fur alle Bestimmungsstaaten mitAusnahme von 
US): SIEMENS AKTIENGES^LLSCHAFT [DE/DE]; 
Wittelsbacherplatz 2, 80333 Mandhen (DE). 

(72) Erfinder; und \ 

(75) Erfinder/Anmelder (nur far ^5>:^REITTER, Johann 



[AT/AT]; Wotzing 16, A-4880 Berg im Atteigau (AT). 

ESELY, Alexander [AT/AT]; Nattergasse 1-3, A-1170 
Wien (AT). 



(74) Gemeinsamer Vertreter: SIEMENS AKTIENGE- 
SELLSCHAFT; Postfach 22 16 34, 80506 MUnchen 
(DE). 

s, 

(81) Bestimmungsstaaten (national): AE, AG, AL, AM, AT, 
AU, AZ, BA, BB, BG, BR, BY, BZ, CA, CH, CN, CR, CU, 
CZ, DE, DK, DM, DZ, EE, ES, H, GB, GD, GE, GH, GM, 
HR, HU, ID, XL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, LK, 
LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, 
MZ, NO, NZ, PL, PT. RO, RU, SD, SE. SG, SI, SK. SL, 
TJ. TM, TR, TT. TZ, UA, UG, US, UZ, VN, YU, ZA, ZW. 

[Fortsetzung auf der ndchsten Seite] 



(54) Title: METHOD AND DEVICE FOR TRANSMITTING IP PACKETS BETWEEN A RADIO NETWORK CONTROLLER 
(RNC) AND ANOTHER ELEMENT OF A MOBILE RADIO NETWORK 

(54) Bezeichnung: VERFAHREN UND VORRICHTUNG ZUM OBERTRAGEN VON IP-PAKETEN ZWISCHEN EINEM RA- 
DIO NETWORK CONTROLLER (RNC) UND FINER WEITEREN EINRICHTUNG FINES MOBILFUNKNETZWERKES 



ITabelle 



B X^l 1 lU I 1 



11 



MT 







* — r 




DCF 
















lu 




Gn 


)CY- 






RNC 


SGSN 


GGSN 






— I-H 


2 




3 






4 






Sa . TABLE 
6. IP NETWORK 
10. EXTERNAL NETWORK 



(57) Abstract: The invention relates to a method for transmitting IP packets between a radio network controller (RNC) (2) and 
another element of a mobile radio network. Said method is characterised in that an IP packet to be transmitted contains a first 
coder-decoder mode indication (TFCI, AMR) which indicates the coder-decoder mode (TFCI, AMR) used to transmit the IP packet 
from a mobile terminal (MT) (1) to a first radio network controller (RNC) (2); a coder-decoder mode indication exchange system 
l/i (DCF) (5) through which an IP packet passes on the way through the mobile radio network exchanges the first coder-decoder mode 
indication (RFCI, AMR) contained in the data packet, with a second coder-decoder mode indication (RFCI requested) which is 
known to another element or mobile terminal (MT) (1) and corresponds Ifo^the first coder-decoder mode indication according to a 
table stored in the coder-decoder mode indication exchange system (5); and' the IP packet containing the second coder-decoder mode 
indication is sent on to other elements. 

O (57) Zusammenfassung: Ein effizientes Verfahren zum IJbertragen von IP-Paketen zwischen einem Radio Network Controller 

O(RNC) (2) und einer weiteren Einrichtung eines Mobilfunknetzwerkes, dadurch gekennzeichnet, dass ein zu tibertragendes IP-Paket 
eine erste Codec-Mode-Angabe (TFCI, AMR) enthalt, welche angibt, 

[Fortsetzung auf der ndchsten Seite J 
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Verdffentlicht: 

— mit internationalem Recherckenbericht 

Zur Erkldrung der Zweibuchstaben-Codes und der anderen Ab- 
kurzungen wird auf die Erkl&rungen ("Guidance Notes on Co- 
des and Abbreviations") am AnfangJederreguldrenAusgabe der 
PCT'Gazette verwiesen. 



mit welchem Codec -Mode (TFCI, AMR) es von einem Mobilen Endgerat (MT) (1) zu einem ersten Radio Network Controller (RNC) 
(2) ubertragen wurde, dass eine von einem IP-Paket auf dem Weg dutch das Mobilfunknetz durchlaufene Codec-Mode- Angaben- A us- 
tausch-Anordnung (DCF) (5) einen Austausch der im Datenpaket enthaltenen ersten Codec-Mode-Angabe (RFCI, AMR) durch 
eine zweite, einer weiteren Einrichtung oder mobilen Endgerat (MT) (1) bekannte, gemSss in einer gespeicherten Tabelle in der 
Codec-Mode-Angaben-Austausch-Anordnung (5) zur ersten Codec-Mode-Angabe korrespondierende zweite Codec-Mode-Angabe 
(RFCI requested) vomimmt, dass das IP-Paket. welches die zweite Codec-Mode-Angabe enthSlt. in weiteren Einrichtung weiteige- 
sandt wird. 
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Beschreibung 

Verfahren und Vorrichtung zum Ubertragen von IP-Paketen 
zwischen einem Radio Network Controller (RNC) und einer 
5 weiteren Einrichtung eines Mobilf unknetzwerkes - 

Die Erfindxing betrif ft ein Verfahren xind eine Vorrichtung in 
einem mobilen Konimunikationsnetzwerk tnit dem bei zu 
ubertragenden IP-Paketen zwischen Mobilfunkteilnehmern 
10 zentral Codec-Mode Wechsel durchgefuhrt werden. 

Aufgabe der vorliegenden Erfindung, ein Verfahren und eine 
Vorrichtung der eingangs genannten Art dahingehend zu 
optitnieren, dass eine Verringerung der Signalisierungslast 
15 durch eine zentrale Behandlung von Codec Mode Wechseln 
erzielt wird. 

Diese Aufgabe wird erf indungsgemaS durch die Gegenstande der 
unabhangigen Patent anspruche bezuglich des Verfahrens und der 

20 Vorrichtung gelost. Weiterbildungen der Erfindung sind in den 
Unteranspruchen angegeben. Die erf indungsgemaiSe Ubertragung 
von IP Paketen zwischen einem Radio Network Controller (RNC) 
und einer weiteren Einrichtung eines Mobilf unknetzwerkes hat 
den Vorteil, dass der Radio Network Controller nicht die 

25 Codec (s) Mode(s) kennen muss, die es derzeit gibt und kunftig 
geben wird. Damit entfSllt ein Software Update bei den Radio 
Network Controllern (RNC) . Der RNC (2) muss ein IP Paket 
(user level IP Paket) , dass vollstandig als Daten gesehen 
wird, offnen. Sorait muss der RNC (2) nicht wissen, wie die 

30 Daten strukturiert sind. Der RNC (2) muss ebenso nicht 

wissen, welcher RTP Protokoll header, IP Protokoll header, 
UDP Protokoll header und RTP payload header verwendet wird. 
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Die Erfindung wird anhand eines in Figuren dargestellten 
Ausfuhrungsbeispiels naher erlautert. Im einzelnen zeigen 



Figur 1 



Figur 2 

Figur 3 
10 Figur 4 
Figur 5 
Figur 6 
Figur 7 

15 Figur 8 



Figur 9 
20 Figur 10 



eine erf indungsgemafie Netzwerk Architektur mit 
einer Vorrichtung (DCF) zur Unterstiitzung eines 
Codec Mode Wechsel 

den Austausch von Codec und Mode betref fenden Daten 
bei einem Anmif 

die Einbindting des Access Netzwerks 

die Einbindung des Core Netzwerks 

die Struktur eines OCS-Frames (OCSF) 

die Information der veirwendeten RAB Teilstrome 

die Bearbeitung eines IP-Paketes bei einem Anruf 

zwischen zwei Mobil en EndgerSten 

die Bearbeitung eines IP-Paketes bei einem Anruf 
zwischen einer Feststation und einem Mobilen 
Endgerat 

das Datenpaket an den einzelnen Stationen fur einen 

Anruf zwischen zwei Mobilen Endgeraten 

das Datenpaket an den einzelnen Stationen fur einen 

Anruf zwischen einem Mobilen Endgerat und einer 

Feststation 



Ein IP Paket wird fUr den Transport zwischen zwei Radio 
25 Netzwerk Control lern in ein Optimized Codec Support Frame 

konvertiert und fur den Transport zwischen dem Radio Netzwerk 
Controller und Mobilen Endgerat aufgeteilt in verschiedene 
RAB Teilstr6me. 



30 Figur 1 zeigt die Netzwerkarchitektur, die fur das Verfahren 
zum Ubertragen von IP -Pake ten zwischen Radio Network 
Controllern (RNC) bei Anrufen zwischen Mobilen Endgeraten 
Anwendung findet. Von einem ersten mobilen Endgerat (1) 
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gelangt ein IP-Paket (z. B. AMR kodierte Sprache) zum Radio 
Network- Controller (2) , das dort in ein OCS-Frame gekapselt 
wird und von dort liber den Serving GPRS Support Knoten (3) 
zum Gateway GPRS Support Knoten (4) weitergeleitet wird. Ein 
5 mobiles Endgerat (1, 11) stellt ein Mobil funkgerat, ein 
Handheld, einen mobilen Computer, eine Kombination der 
genannten Gerate oder ahnliches dar. Hierfur hat der RNC (2) 
eine Tabelle, die dynamisch beim Verbindungsaufbau erstellt 
wird, um den TPCI Wert mit dem korrespondierenden RFCI Wert 

10 und den TFCI req. Wert mit dem korrespondierenden RFCI req. 
Wert austauschen zu k5nnen. Dabei wird dem RNC (2) die 
Information (RANAP: RAB assignment) gegeben, die ihn 
befahigt, aufgrund der aktuellen Situation auf der 
Luf tschnittstelle, den entsprechenden Codec Mode vorzugeben. 

15 Es ist nicht notwendig, dass der RNC (2) den Codec Mode 

kennt, sehr wohl jedoch die Charakteristiken von diesem (z. 
B- benotigte Bandbreite) . Das OCS Frame hat die Pelder RFCI, 
RFCI req., optionale Felder und das IP Paket, wobei die 
Reihenfolge der Felder in der Implement ierungsphase 

20 festgelegt wird. Der Transport erfolgt z. B. mittels eines 

GTP-U Header, der von dem RNC (2) erstellt wird. Der GGSN (4) 
gibt das OCS-Frame an die Codec-Mode-Angaben-Austausch- 
Anordnung (DCF) (5) und diese liberprttft anhand einer Tabelle 
{5a) die verwendeten Codec Mode Angabe und tauscht diese 

25 gegebenenfalls durch eine andere aus. Dabei kann das OCS 

Frame zwischen dem GGSN (4) und der DCF (5) in einem Stfick 
(ein Argument) oder in verschiedenen Argumenten aufgeteilt 
(RFCI = Argument 1, RFCI req. = Argument 2, IP Paket « 
Argument 3) transport iert werden. Die Codec -Mode-Angaben- 

30 Austausch-Anordnung (DCF) (5) kann als zentrale Einrichtung 
Oder dezentrale Einrichtung in einem Kommunikationsnetzwerk 
integriert werden. Dabei kann die DCF (5) ein eigener Knoten, 
eine Einrichtung des GGSN (4) oder eines anderen Knotens 
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sein- Bei einer zentralen DCF (5) wird der RFCI Wert vom 
Sender auf den RFCI Wert des Empf angers und der RFCI req. 
Wert des Senders auf den RFCI req. Wert des Empf angers 
utngewandelt . Eine weitere Aufgabe der DCF (5) ist es den 
5 angefragten Codec Mode (dargestellt durch den AMR req. Wert) 
mit dem RFCI req. Wert zu vergleichen. Sind diese 
unterschiedlich, tauscht das DCF (5) den AMR req. Wert ent- 
sprechend des RFCI req. Wertes aus. 

Bei je einer DCF (5) pro G6SN (4) erhalt die DCF (5) einen 

10 RFCI Wert, einen RFCI req. Wert \md das IP Paket vom GGSN 

(4) . Daraufhin vergleicht die DCF (5) den AMR Codec Mode req. 
mit dem RFCI req. Wert und tauscht den AMR req. Wert aus, 
wenn die Werte nicht zu einander passen. Fur die Empfanger- 
Richtung wird vom GGSN (4) anhand eines Indikators (z, B. TFT 

15 Auswertung) das IP Paket zur DCF (5) weitergeleitet und dort 
werden der AMR Codec Mode und der AMR Codec Mode req. 
festgestellt und durch den entsprechenden RFCI Wert und RFCI 
req. Wert ersetzt. Der Unterschied zwischen einer zentralen 
und einer dezentralen DCF (5) ist nun, dass bei dezentraler 

20 DCF (5) fur einen Anruf zwischen zwei Mobilen Endger&ten (1, 
11) zweimal ein DCF Aufruf erfolgt. Der Austausch kann z- B. 
lastabh&ngig vom RNC (2) an die DCF (5) anhand des RFCI req. 
Wertes angewiesen werden. Das DCS -Frame wird wieder zum GGSN 
(4) gesandt und weitergeleitet zu einem Empf&nger Mobilen 

25 Endgerat (11) uber die einzelnen Knoten SGSN (3) und RNC (2) . 
Die Entkapselung geschieht wieder im RNC (2) . Ist der 
Empf anger eine Fest station (15) , so wird das IP Paket vom 
GGSN (4) Oder von der DCF (5) selbst uber eine Firewall (8) , 
dem Internet (9) und einem extemen Netzwerk (10) an diese 

3 0 weitergeleitet. 

Figur 2 zeigt, wie die fur einen Anruf verwendeten Codec (s) 
Mode(s) zwischen zwei Mobilen Endgerat-en 1 und 11 -die 
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bestinimt werden. Dabei muss sichergestellt sein, dass ein 
Mobiles Endgerat (1) einen Tr&ger (Bearer) fur den Transport 
von z. B. SIP Nachrichten (messages) festgelegt hat. Die SIP 
Nachrichten enthalten eine Liste mit alien mdglichen zu 
verhandelnden Codec (s) iy[ode(s) aus Sicht des Anrufers. Das 
Mobile Endgerat (1) sendet eine SIP Nachricht mit zxm 
Beispiel SDP Inf ormationen, die die vorgeschlagenen Codec (s) 
Mode(s) enthalt. Das SDP Protokoll ist ffir den Transport von 
Codec (s) Mode(s) bevorzugt, jedoch konnen auch andere 
Protokolle, wie html oder xml verwendet werden. Das 
angerufene Mobile EndgerSt (11) sendet als Antwort Codec (s) 
Mode(s) mit denen es das GesprSch durchfiihren m6chte. Die 
Call State Control Fianktion (CSCF) (7) des IP Multimedia 
Siabsystems (IMS) , welche fiber das IP Netzwerk (6) erreicht 
werden kann, kann bei der Festlegung der verwendeten Codec (s) 
Mode(s) eingreifen, falls andere Codec (s) Mode(s) als die von 
den mobilen EndgerSten (1, 11) vorgeschlagenen verwendet 
werden sollen. Das IP Netzwerk stellt das sogenannte 
Operator spezific IP Network (3GPP 29061) dar. Beide Mobile 
Endgerate sind nun bereit fur die Obertragung von Codec (s) 
Mode(s), die auf beiden Seiten umgesetzt werden k6nnen. Bei 
AMR kodierter Sprache muss das Mobile Endgertt die 
ubertragenden Codec (s) Mode(s) in z. B. SDU Parameter 
konvertieren. Wenn die CSCF (7) oder ein anderer, bei der 
Ubertragxing der Codec (s) Mode(s) wShrend des Gesprachsaufbaus 
beteiligter Knoten bereits Codec (s) Mode(s) in SDU Parameter 
konvertiert hat, so ist es notwendig zur Verbesserung des SDP 
Oder des SIP Protokolls, dass die SDU Parameter an die Mobile 
Endgerate (1, 11) weitergeleitet werden. Die Sequenz der SDU 
Parameter kann identisch sein zu den iibertragenen Codec (s) 
Mode(s) in der SIP/SDP Liste, die die ausgehandelten Codec (s) 
Mode ( s ) enthal t . 
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Figur 3 zeigt die Initialisierung des Access Netzwerks. Dabei 
kennt der SGSN (3) die Codec (s) Mode (s) , die fur den Anruf 
verwendet werden sollen. Dies geschieht z. B. liber SDU 
Parameter. Die 3GPP Session Management Protokoll Prozeduren 
5 ^'Aktiviere PDP Kontext", ^'Modif iziere PDP Kontext" oder 

^'Aktiviere Sekundar PDP Kontext" werden fur die SDU Parameter 
Ubertragung (mit der gleichen Sequenz, wie die 
korrespondierenden Codec (s) Mode (s) der Codec (s) Mode(s) 
Ubertragung) erweitert, was die Codec (s) Mode(s) am SGSN (3) 

10 ausdruckt . Dabei wird erreicht, dass der SGSN (3) liber den 
Typ des Dienstes nicht Bescheid weiS, was heiSt, dass der 
SGSN (3) nicht mit alien verschiedenen Codec (s) Mode(s) 
initialisiert werden muss, die fur einen Anruf angefragt 
werden konnten. Der SGSN (3) weifi also nichts von dem 

15 ubertragenen Dienst. Die RANAP (RAB Zuweisung) Anfrage, 

welche die an die Mobile Endgerate gegebenen SDU Parameter 
enthalt, ruft der SGSN (3) f\ir die tJbertragung auf . Die RRC 
Protokoll Meldung, welche die RAB Teilstr6me gemafi der SDU 
Parameter best immt wird vom RNC (2) angerufen. Die 

20 Headerf elder (Transport Format Combination Identifier) TFCIs 
und (RAB SubFlow Combination Identifier) RPCIs in 
Datenpaketen sind gespeichert im RNC (2) fUr den Anruf gemaS 
der erhaltenen SDU Parameter. Die Sequenz der TFCIs und RPCIs 
korrespondiert mit den erhaltenen SDU Parameter. TFCIs und 

25 RFCIs werden fur die Kennzeichnung der Codec (s) Mode(s) 

verwendet, ohne dass der RNC (2) Kenntnis liber die Codec (s) 
Mode(s) hat. Damit muss der RNC (2) nichts von den 
(ibertragenen Diensten wissen. Wenn das Setup der RAB 
Teilstrome erfolgreich beendet wurde, wird die RRC Protokoll 

30 Meldung gesandt von den RAB Teilstromen, dass der 

Verbindungsaufbau komplett ist. Die mobilen Endgerate (1, 
11) , der RNC (2) und die DCF (5) sind die Instanzen, welche 
die Abbildung der RFCIs in SDU Parameter kennen. 
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Figur 4 zeigt die Initialisierung der Codec (s) Mode(s) in 
einem Core Netzwerk. Fur Anrufe zwischen einer Feststation 
und einem mobilen Endgerat sowohl als auch zwischen zwei 
5 mobilen Endgeraten weilS die DCF (5) welche RFCIs fiir welche 
SDU .Parameter stehen. Damit ist die Abbildimg zwischen RFCIs 
vmd deren korrespondierenden Codec (s) Mode(s) und die 
Urawandlung eines IP Paketes in ein OCS-Frame bereit. 
Altemativ kann die DCF (5) bei Anrufen zwischen zwei mobilen 

10 Endgeraten die Werte der RFCI und des angefragten RFCI 

austauschen, da der RNC (2) einen Typ eines SDU Parameters 
ausdrucken, der fur einen spezifischen Codec Mode mit einen 
anderen RFCI als der korrespondierenden RNC (2) , der das 
korrespondierende Empf anger Mobile Endgerat (11) bedient. Zur 

15 Vereinf achung sollten die verwendeten RFCIs die gleiche 

Sequenz, wie die SDU Parameter und die SIP/SDP verbundenen 
Codec (s) Mode(s) haben. Die DCF (5) verwendet eine Tabelle um 
die RFCIs und urn die OCS- Frames in IP Pakete und umgekehrt 
konvertieren zu konnen. In der Tabelle sind die RFCIs und die 

20 korrespondierenden SDU Parameter, sowie die Tunnel Endpunkt 
Identifizierer (Tunnel Endpoint Identifier) fur PDP Kontexte 
fur das Abbilden der korrespondierenden RFCIs enthalten. Nach 
posit iver Antwort durch die RRC Rufaufbau Meldung, antwortet 
der RNC (2) mit einer RANAP Meldung und fugt fiir den Anruf 

25 die RFCIs und ihre Bedeutung hinzu. Der SGSN (3) sendet iiber 
einen GTP-C Erweiterungs -Header, die RFCIs und ihre Bedeutxing 
zum GGSN (4) . Nach Erhalt sendet der GGSN (4) die RFCIs und 
ihre Bedeutung zur DCF (5) , wo die Initialisierung fur das 
Gesprach stattfindet. Die DCF (5) ist nun vorbereitet fur das 

30 Speichern der RFCIs und dem Konvertieren von IP Paketen in 
OCS -Frames und umgekehrt. 
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Figur 5 zeigt die Struktur eines OCS Frames. Der verwendete 
Codec Mode wird durch den RFCI - Wert bei dem OCS Frame, 
Weitere Tabellenf elder im Datenpaket konnen optional 
hinzugefugt werden. Sie mussen jedoch vom Etnpf anger 
5 interpret ierbar sein. Das IP Header Feld beinhaltet die 

Informationen fiir die Regkonf igurierung des IP Pakets Header. 
Einige Infoarmationen des OCS Frame konnten auf uber einen GTP 
Erweiterungs -Header libermittelt werden, dies hangt jedoch von 
der Standardisierung bzw. Implement ierung in einem Netzwerk 
10 ab. 

Figur 6 zeigt die Tabelleninf ormationen fur die Aufteilung in 
verschiedenen RAB Teilstrome 

15 Figur 7 zeigt, wie ein IP Paket von einem mobilen Endgerat 

(1) xiber einzelne Netzwerknoten zu einem anderen mobilen 
Endgerat (11) ubertragen wird. Ein zu versendendes IP Paket 
wird vom mobilen Endgerat (1) in verschiedene RAB TeilstrSme 

(12) aufgeteilt. Dabei werden die Werte fiir TFCI, TFCI req. 

20 und eventuell weitere Werte mit Werten, die aus dem IP Paket 
stammen, ausgefiillt. Die RAB TeilstrSme (12) transport ieren 
das IP Paket zum RNC (2) . Eine Header Kompression^ wie der 
IP/UDP/RTP Header uber die Luf tschnittstelle ist optional. Im 
RNC (2) werden der Wert fur TFCI mit dem korrespondierenden 

25 Wert fiir RFCI und der Wert fiir TFCI req. mit den 

korrespondierenden Wert fur RFCI req. ausgetauscht . Der RNC 

(2) hat hierfiir eine geeignete Tabelle oder ein Array. Als 
Resultat sind die in RAB Teilstrome (12) unterteilten IP 
Pakete in OCS Frames konvertiert. Danach wird vom RNC der 

30 GTP-U Header erstellt und dem OCS-Frame (13) vorangestellt 
und liber den Seirving GPRS Support Knoten (SGSN) (3) zum 
Gateway GPRS Support Knoten (GGSN) (4) weitergeleitet . Der 
GGSN (4) leitet das Frame zu der Codec- Mode -Angaben- 
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Austausch-Anordnung (DCP) (5) weiter. Bei einer' zentralen DCF 
(5) tauscht diese die RFCI und RPCI req. Werte zwischen den 
beiden mobilen Endgeraten (1, 11) aus. Zusatzlich vergleicht 
die DCF (5) den AMR req. Wert im IP Paket mit dem RFCI req. 
Wert und tauscht ihn gegebenenf alls aus. Bei einem DCF (5) 
pro GGSN (4) entfernt die DCF (5) den RFCI und RPCI req. Wert 
und uberschreibt den AMR req. Wert mit dem RFCI req. Wert. 
Gibt nur das IP Paket an den GGSN (4) zurCick und dieser fugt 
den GTP-U Header (plus den GTP-U Erweiterungs -Header) und 
sendet das Paket in Richtung den Empf anger RNC (2) bei einem 
Anruf zwischen zwei mobilen Bndgerate (1, 11) . Vorher wird 
das IP Paket uber den Empf anger GGSN (4) zum Empf anger DCP 
(5) geleitet und es werden die fur das Mobilf undendgerat (11) 
ausgehandelten RFCI uxid RFCI req. Werte gesetzt und wieder 
zum GGSN (4) zurOickgesandt . 1st der Empf anger eine 
Feststation (15) wird das IP Paket sofort vom GGSN (4) 
weitergeleitet . 

Der GGSN (4) kann ieventuell den GTP-U Header austauschen bzw. 
modifizieren und das OCS Frame (13) zum SGSN (3), der dieses 
zum RNC (2) weiterleitet , senden. Der RNC (2) ersetzt den 
RFCI Wert durch den korrespondierenden TFCI Wert und den RFCI 
req. Wert durch den korrespondierenden TFCI req. Wert und 
teilt das IP Paket in mehrere RAB Teilstrome (14) auf , die 
das IP Paket liber die Luf tschnittstelle zum mobilen Endgerat 
(11) weiterleiten. 

Figur 8 zeigt die Umwandlung und das Versenden eines IP 
Paketes bei Anruf en zwischen einem mobilen Endgerat (1) und 
einer Feststation (15) . Bei Anruf en von einem mobilen 
Endgerat (1) zu einer Feststation (15) konvertiert die DCF 
(5) ein IP Paket in ein OCS Frame und umgekehrt. Ein IP 
Paket, welches auf dem uplink (vom mobilen Endgerat zum RNC) 
versandt wird, wird von dem mobilen Endgerat (1) in RAB 
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Teilstrome (12) aufgeteilt und zum RNC (2) weitergeleitet. 
Die Werte fiir TFCI, TFCI req. und optionale Werte stammen 
dabei aus dem IP Paket (AMR und AMR req. Wert) . Der IP 
Datenpaket Header und die verschlusselten Daten warden 
5 ebenfalls aus dem IP Paket genoramen. Eine Header-Kompression, 
- 2. B. der IP/UDP/RTP Header uber die Luftschnittstelle ist 
optional. Der RNC (2) tauscht den TFCI Wert mit dem 
korrespondierenci^n RFCI Wert und den TFCI req. Wert mit dem 
korrespondierenden RFCI req. Wert aus. Damit sind die RAB 

10 Teilstrome (12) in ein OCS Frame konvertiert. Danach wird vom 
RNC (2) der GTP-U Header dem OCS Frame vorangestellt und iiber 
den SGSN (3) zumi GGSN (4) weitergeleitet. Der GGSN (4) 
entkapselt das OCS Frame (13) und erkennt z. B. durch einen 
Tunnel Endpunkt Identif izierer (Tunnel Endpoint Identifier) 

15 des GTP-U Headers, dass das OCS Frame mit GTP-U (13) , das 
zuvor in ein IP Paket konvertiert werden muss, zu der 
Feststation (15) gesandt werden soil. Pur die Konvertierung 
leitet der GGSN (4) das OCS Frame (13) ohne den GTP-U Header 
zum DCF (5) weiter. Das DCF (5) konvertiert das Frame und 

20 leitet es wieder an den GGSN (4) zuruck. SchlieSlich wird das 
IP Paket in Richtxing der Feststation (15) vom GGSN (4) weiter 
gesandt. Altemativ konnte das IP Paket direkt, ohne dass es 
wieder zum GGSN (4) zuriick geleitet werden muss, durch die 
DCF (5) in Richtung der Feststation (15) weitergeleitet 

25 werden. 

Erhalt der GGSN (4) ein IP Paket von der Feststation (15) 
zurCick, so wird es mit einem spezifischen PDP Kontext 
gekennzeichnet , gemafi z. B. der IP-Adresse oder dem TFT 
Filter, wenn mehr als ein PDP Kontext fur das Mobile Endgerat 
30 (1) aktiviert ist. Mit der Kennzeichnung weiS der GGSN (4), 

dass er das IP Paket zum DCF (5) weiterreichen muss, damit es 
dort zu einem OCS Frame konvertiert wird. Zusatnmen mit einem 
Identif izierer (Identifier) , der die korrespondierenden RPCIs 
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und RFCI req. abfragt, wird das IP Paket zum Konvertieren in 
ein OCS Frame zur DCF (5) weitergeleitet und danach wieder 
zuruck zum GGSN (4) . Als nachstes wird der GTP-U Header dem 
OCS Frame vorangestellt xind zum SGSN (3) gesendet, der dieses 
5 Frame (13) zum RNC (2) weiterleitet . Nachdem der GTP-U Header 
entfernt wurde, tauscht der RNC (2) den RFCI Wert mit dem 
korrespondierenden TFCI Wert und den RFCI req. Wert mit dem 
korrespondierenden TFCI req. Wert aus, teilt das IP Paket in 
RAB Teilstrome (12) auf xand sendet es zum mobilen Bndgerat 
10 (1), das es wieder zusammensetzt . 

Ausfiihrung einer Codec Mode Wechsel Auf forderung beim mobilen 
Endgerat 

15 Die Anfrage zum Digital isieren von Daten mit einem anderen 
Codec Mode wird in-band durch eine Applikation, die sich in 
einem mobilen Endgerat, einem Computer oder ahnlichem 
befindet, von dem Mobilf unknetz erhalten. Ein Codec Mode 
Wechsel wird vom RNC (2) veranlasst. Dies kann uplink durch 

20 das Mobile EndgerSt (1, 11) geschehen, das durch den TFCI 

req. Wert einen bestimmten Codec Mode anfordert und vom RNC 
beauf sichtigt wird und downlink wird das Empf anger Mobile 
Endgerat (1, 11) aufgefordert liber den RFCI req. Wert einen 
anderen Codec Mode zu verwenden. Dieser Wert wird vom RNC (2) 

25 beauf sichtigt \ind wenn gegebenenf alls korrigiert bevor er ihn 
in den TFCI req. Wert tauscht. Er kann auch vom Mobilen 
Endgerat (z. B. mit einem RTP Nutzlast (payload) header Feld 
AMR req.)/ unter Aufsicht des RNC (2), veranlasst werden. 
Wegen der Luf tschnittstellen-Qualitats-Berichte, die von 

30 einem kodierten Daten empfangenden Mobilen Endgerat (11) an 
das bedienende RNC (2) gesandt werden, oder durch einen 
Ausloser (Trigger), wie z. B. die Tageszeit, kann der RNC (2) 
an dem sendenden Mobilen Endgerat (1) einen Codec Mode 
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Wechsel anfordern, der durch Modif izierung des RFCI req. 
Wertes des OCS Frames, das an das sendende Mobilen Endgerat 
gesandt wird, realisiert wird. Der RNC (2) kann die Anfrage 
nach einem Codec Mode Wechsel uber den SGSN (3) gemtS der 
aktuellen Situation (z. B. aktuell verwendete Bandbreite land 
Tageszeit) beeinf lussen. Das Mobile Endgerat erhalt eine 
Codec Mode Wechsel Anfrage uber den TFCI req. Wert. Die 
Applikation im Mobilen Endgerat erhalt die gleiche Codec Mode 
Wechsel Anfrage uber einen Feld-Wert aus dem IP Paket; wie z. 
B. den RTP Nutzlast (payload) Header Feld (field) AMR req. IF 
1. Danach wird das IP Paket digitalisiert mit dem angefragten 
Codec Mode, zur Lower Layer (Unteren Schicht) (z. B. PDCP 
Layer) weitergeleitet • Der Lower Layer kann das Feld, welche 
die Informationen liber die verwendete Codec Mode enthalt, des 
IP Paketes interpretieren. Als Resultat uberpriift er die 
erhaltenen IP Pakete nach dem Codec Mode, der mit dem TPCI 
req. Wert korreliert und lasst entweder das IP Paket 
passieren oder verwirft es. Das Mobile Endgerat kodiert Daten 
mit der Codec Mode, die vom RNC (2) angefragt wurde. 
Andererseits fallt die Qualitat des Anrufs dramatisch wegen 
der verlorenen Pakete. 

Ausfuhriing einer Codec Mode Wechsel Anfrage bei der DCF 

Die DCF erhalt die Codec Mode Wechsel Anfrage in Form eines 
RFCI req. Wertes. Die Applikation erhalt die gleiche Anfrage 
in Form eines entsprechenden Peldes im IP Paket. Die 
Applikation, die sich auf einer Feststation befindet, kodiert 
weiterhin Daten mit dem angefragten Codec Mode, den es aus 
dem entsprechenden Feld im IP Paket hat. Danach wird das IP 
Paket mit dem angefragten Codec Mode laber den GGSN (4) zum 
DCF (5) gesendet. 
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Als Result at iiberpruft die DCF (5) in diesem erhaltenen IP 
Paket den Codec Mode, ob er mit dem RPCI req. Wert korreliert 
und lasst entweder das IP Paket passieren oder verwirft es. 
Die Ubertragung der IP Pakete uber die Luf tschnittstelle kann 
5 transcodiert oder nicht transcodiert geschehen. 

Figur 9 zeigt das Aussehen des Datenpakets an den einzelnen 
Stationen bei einen Anruf zwischen zwei Mobilen Endgeraten, 
Die Reihenfolge der Felder wird aufgrund der Implement ierung 
und der Standardisiening festgelegt. Die Information 
(RFCI/TFCI - Wert und AMR-Wert, RFCI req./TFCI req. - Wert 
und AMR req. - Wert) uber die Codec Mode werden in dem 
vorliegenden Beispiel doppelt libertragen. Um dies noch zu 
beseitigen, wird zwischen dem Mobilen Endgerat (1, 11) und 
der DCF der RTP Nutzlast (payload) Header (enthalt AMR Wert 
und AMR req. Wert) modifiziert, dies bedeutet, dass ein IETF 
Protokoll geandert wird. 

Figur 10 zeigt das Aussehen des Datenpakets an den einzelnen 
20 Stationen bei einem Anruf zwischen einem Mobilen Endgerat und 
einer Fest station. Die Reihenfolge der Felder wird aufgrund 
der Implement ierung und der Standardisiening festgelegt. 
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Patentanspriiche 

1. Verfahren zum Ubertragen von IP-Paketen zwischen einem 
Radio Network Controller (RNC) (2) xind einer weiteren 
5 Einrichtung eines Mobilfianknetzwerkes, 

dadurch gekennzeichnet, 

dass ein zu ubertragendes IP-Paket eine erste Codec-Mode- 
10 Angabe (TFCI, AMR) enthalt, welche angibt, mit welchem 

Codec-Mode (TFCI, AMR) es von einem Mobilen Endgerat (MT) 
(1) zu einem ersten Radio Network Controller (RNC) (2) 
ubertragen wurde, 

dass eine von einem IP-Paket auf dem Weg durch das 
15 Mobilfunknetz durchlaufene Codec -Mode- Angaben-Aust ausch- 

Anordnung (DCF) (5) einen Austausch der ira Datenpaket 
enthaltenen ersten Codec -Mode -Angabe (RFCI, AMR) durch 
eine zweite, einer weiteren Einrichtung oder mobilen 
EndgerSt (MT) (1) bekannte, gemaS in einer gespeicherten 
20 Tabelle in der Codec -Mode -Angaben-Austausch-Anordnung (5) 

zur ersten Codec -Mode -i^gabe korrespondierende zweite 
Codec -Mode -Angabe (RFCI requested) vornimmt, 
dass das IP-Paket, welches die zweite Codec -Mode -Angabe 
enthalt, zur weiteren Einricht\ang weitergesandt wird. 



25 



2. Verfahren nach Anspruch 1, 
dadurch gekennzeichnet , 



30 



dass als weitere Einrichtung eines Mobilfunknetzes ein 
Radio Network Controller (RNC) (2) bei einem Anruf 
zwischen zwei mobilen Endgeraten (1, 11) verwendet wird. 
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3 . Verf ahren nach einem der vorhergehenden Anspriiche, 



dadur ch gekennze i chne t , 

5 dass als weitere Einrichtiing eines Mobil fimknetzes eine 

Schnittstelle (Gateway) bei einem Anruf zwischen einem 
mobilen Endgerat (1) und einer Fest station (15) verwendet 
wird- 

10 4. Verf ahren nach einem der vorhergehenden Anspriiche, 
dadurch gekennzeichnet, 

dass in einer Tabelle einer Codec -Mode -Angaben- 
15 Korrespondenz-Speichereinrichtung (5) bei Initialisieren 

einer Verbindung zwischen zwei Mobilen Endgeraten (MT) (1, 
11) mindestens eine erste Codec -Mode -Angabe (TFCI, AMR) 
und zugeh6rige zweite Codec -Mode -Angabe (TFCI requested, 
AMR requested) abgespeichert wird. 

20 

5. Verf ahren nach einem der vorhergehenden Anspriiche, 
dadurch gekennzeichnet, 

25 dass in einem von einem Mobilen Endgerat kommenden, eine 

Code -Mode -Angabe in Form eines TFCI-Wertes und AMR-Wertes 
enthaltenden Datenpaket von dem das Datenpaket 
empf angenden Radio Network Controller (RNC) (2) der TPCI- 
Wert gegen eine Codec -Mode -Angabe in Form eines RFCI- 

30 Wertes ausgetauscht wird. 



6. Verf ahren nach einem der vorhergehenden Anspriiche, 
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dadurch gekennzeichne t , 

dass die TFCI-Angaben und die RPCI-Angaben einen Codec- 
Mode reprasentieren. 

7. Verfahren nach einem der vorhergehenden Anspriiche, 

dadurch gekennze ichne t , 

10 dass fur Anrufe zwischen Mobilen EndgerSten (MT) (1, 11) 

der Radio Netzwerk Controller (RNC) (2) SDU Parameter, die 
einen spezifischen Codec-Mode mit einem RFCI-Wert 
reprasentieren/ ausgeben kann, der von der Codec -Mode - 
Angaben-Austausch-Anordnung (DCF) (5) mit dem RFCI-Wert 

15 und dem angefragten RFCI-Wert ausgetauscht wird. 



8. Verfahren nach einem der vorhergehenden Anspruche, 



dadurch gekennzeichne t , 

20 

dass das IP Paket in ein Optimized Codec Support Frame- 
Format (OCSF) fur den Transport in einem GTP Txinnel 
konvertiert und in RAB Teilstrome (12) fur den Transport 
zwischen Radio Network Controller (RNC) (2) und Mobiles 
25 Endgerat (MT) (1) aufgeteilt wird. 

9. Verfahren nach einem der vorhergehenden Anspruche^ 

dadurch gekennzeichnet , 

30 

dass die Art des Codec Modes im Optimized Codec Support 
Frame (OCSF) durch den RFCI Wert angezeigt ist. 
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dass der Mode, mit welchem der Sender die Daten kodieren 
mochte im Optimized Codec Support Frame (OCSF) durch den 
RFCI requested - Wert angezeigt wird, 
dass die Reihenfolge der Pelder abhangig von der 
5 Implement iening und Standardisierung ist und 

dass andere Felder bei Bedarf hinzugefflgt werden, wenn der 
Empf anger fiir deren Interpretation vorbereitet ist. 

10. Verfahren nach einem der vorhergehenden Anspriiche, 

10 

dadurch gekennzeichnet, 

dass ein von einem Mobilen Endgerat (MT) (1) gesendetes IP 
Paket in RAB Teilstrome (12) aufgeteilt und mit Werten fur 
15 TFCI und TFCI requested versehen und zum Radio Network 

Controller (RNC) (2) gesandt wird. 

11. Verfahren nach einem der vorhergehenden Anspruche, 

20 dadurch gekennzeichne t , 

dass im Radio Network Controller (RNC) (2) der TFCI -Wert 
xind der TFCI requested - Wert mit dem korrespondierenden 
RFCI -Wert dem RFCI requested - Wert des Optimized Codec 
25 Support Frame (OCSF) ausgetauscht werden. 

12. Verfahren nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, 

30 

dass dem Optimized Codec Support Frame (OCSF) der GTP-U 
header vom Radio Network Controller (RNC) vorangestellt 
und zum Gateway GPRS Support Knoten (GGSN) (4) uber den 
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Serving GPRS Support Knoten (SGSN) (3) waiter geleitet 
wird . 

13. Verfahren nach einetn der vorhergehenden Anspruche, 

5 

dadur ch gekennzei chne t , 

dass der Optimized Codec Support Frame (OCSP) vom Gateway 
GPRS Support Knoten (GGSN) an die Codec-Mode-Angaben- 
Austausch-Anordnung (DCF) (5) weitergeleitet wird, 
dass die korrespondierenden RFCI-Werte xind RPCI requested 
- Werte mit dem Codec Mode des Empfanger Mobilen 
Endgerates (MT) (1) abgeglichen werden, 

dass der modif izierte Optimized Codec Support Frame (OCSP) 
an den Gateway GPRS Support Knoten (GGSN) (4) 
zuruckgesandt wird. 

14. Verfahren nach einem der vorhergehenden Anspruche, 

20 dadurch gekennze i chne t , 

dass das IP Paket durch die Codec -Mode- Angaben-Aust ausch- 
Anordnung (DCF) (5) modifiziert wird, 

dass vom Gateway GPRS Support Knoten (GGSN) (4) mindestens 
ein weiteres Mai die Codec -Mode -Angaben- Austausch- 
Anordnung (DCF) (5) fur die Generierung des Optimized 
Codec Support Frame (OCSF) angeirufen wird, 

dass mindestens ein Gateway GPRS Support Knoten (GGSN) (4) 
beteiligt ist . 

IB.Verfahren nach einen der vorhergehenden Anspriiche, 



10 



15 



25 



30 



dadurch gekennze i chne t , 
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dass vom Gateway GPRS Support Knot en (GGSN) (4) der GTP-U 
header modifiziert bzw. ausgetauscht wird und der 
Optimized Codec Support Frame (OCSF) zum Serving GPRS 
Support Knot en (SGSN) (3) , der es zum Radio Network 
Controller (RNC) (2) weiterleitet , libermittelt wird, 
dass vom Radio Network Controller (RNC) (2) der RFCI-Wert 
mit dem korresponierenden TFCI-Wert ausgewechselt wird, 
dass der RFCI requested gegen dem TFCI requested Wert 
ausgetauscht bzw. modifiziert wird, 

dass das IP-Paket iiber die RAB Teilstrome (12) an das 
Mobile Endgerat (MT) (1) gesandt wird. 

le.Verfahren nach einem der vorhergehenden Ansprviche, 

dadurch gekennzei chnet , 

dass der Optimized Codec Support Frame (OCSF) bevor es zu 
einer Fest station (FT) (15) gesandt wird, von der Codec- 
Mode -Angaben-Austausch-Anordnung (DCF) (5) in ein IP Paket 
konvertiert wird, 

dass das IP Paket von der Codec-Mode-Angaben-Austausch- 
Anordnung (DCF) (5) an den Gateway GPRS Support Knoten 
(GGSN) (4) Oder direkt in Richtung Peststation (FT) (15) 
gesendet wird. 

17.Verfahren nach einem der vorhergehenden Ansparuche, 

dadurch gekennzei chnet , 

dass der Codec Mode Wechsel durch den Radio Network 
Controller (RNC) (2) ausgelost wird. 
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dass der Codec Mode Wechsel in dem Mobilen Endgerat (MT) 
(1) unter Aufsicht des Radio Network Controller (RNC) (2) 
ausgelost wird. 



10 



25 



IS.Vorrichtung zum Selektieren von zwischen Endgeraten 
{ibertragenen mit ausgehandelten Codec Modes kodierten 
Datenpaketen 

dadurch gekennzeichnet. 



dass sie eine in einer zentralen Codec -Mode- Angaben- 
Austausch-Anordnung (DCP) (5) gespeicherten Tabelle zum 
Vergleich des RFCI-Wertes mit einem zweiten RFCI Wert 
aufweist, 

15 dass die Vorrichtung (DCF) (5) eine Einrichtung zum Kon- 

vertieren von IP-Datenpaketen in Optimized Codec Support 
Frames (OCSF) und zum Vergleichen der gelisteten RFCI- 
Werte mit den in den Datenpaketen angegebenen RFCI--Werte 
umf asst , 

20 dass die Vorrichtung (DCF) (5) eine Einrichtung zum 

Riickkonvertieren von C^timized Codec Support Frame (OCSF) 
in IP-Datenpaketen umf asst. 



19 .Vorrichtung nach Anspruch 16 
dadurch gekennze i chne t , 



dass die Vorrichtung (DCF) (5) eine Einrichtimg des 
Gateway GPRS Support Knotens (GGSN) (4) Oder eines anderen 
3 0 Knotens ist. 



20 .Vorrichtung nach Anspruch 16 
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dadurch. gekennzeichnet / 



dass die Vorrichtung (DCF) (5) ein eigener Knoten mit 
Zugang iiber ein IP Protokoll ist. 
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